home *** CD-ROM | disk | FTP | other *** search
/ United Public Domain Gold 2 / United Public Domain Gold 2.iso / utilities / pu696.dms / pu696.adf / XPR_Libs / xprkermit.doc < prev    next >
Text File  |  1994-04-05  |  27KB  |  544 lines

  1.                               XPR Kermit
  2.                              Version 2.30
  3.                            February 14, 1993
  4.  
  5.                   Frank da Cruz - Columbia University
  6.                Stephen R. Walton - Cal State Northridge
  7.  
  8. This is an implentation of an External Protocol (XPR) library for the
  9. Kermit file transfer protocol.  In keeping with the Kermit documents,
  10. here is a list of the items supported and not supported.
  11.  
  12. XPR Kermit Capabilities At A Glance:
  13.  
  14.   Local operation:                   Yes
  15.   Remote operation:                  Yes
  16.   Transfer text files:               Yes
  17.   Transfer binary files:             Yes
  18.   International text:                No
  19.   Wildcard send:                     Yes, if supported by comm program
  20.   File transfer interruption:        Yes
  21.   Filename collision actions:        Yes
  22.   Can time out:                      Yes
  23.   8th-bit prefixing:                 Yes
  24.   Repeat count prefixing:            Yes
  25.   Alternate block checks:            Yes
  26.   Automatic parity detection:        No
  27.   Dynamic packet length:             Yes
  28.   CONNECT mode:                      *
  29.   Terminal emulation:                *
  30.   Key mapping:                       *
  31.   Communication settings:            *
  32.   Transmit BREAK:                    *
  33.   Support for dialout modems:        *
  34.   TCP/IP support:                    *
  35.   X.25 support:                      *
  36.   IBM mainframe communication:       *
  37.   Transaction logging:               No
  38.   Session logging:                   No
  39.   Debug logging:                     No
  40.   Packet logging:                    No
  41.   Act as server:                     No
  42.   Talk to server:                    Yes
  43.   Advanced server functions:         No
  44.   Security for server:               No
  45.   Local file management:             N/A
  46.   Command/Init files:                N/A
  47.   Long packets:                      Yes
  48.   Sliding Windows:                   Yes
  49.   File attributes packets:           Yes, but limited by XPR protocol
  50.   Command macros:                    *
  51.   Script programming language:       *
  52.   Raw file transmit and capture:     *
  53.  
  54. The items marked with a '*' above are those which are to be provided by
  55. the calling terminal emulation program.  Notice that, although XPR
  56. Kermit itself cannot be a "Kermit server," often the communication
  57. program's scripting capability will allow XPR Kermit to be used for the
  58. unattended transfer of files between the Amiga and a remote machine.
  59.  
  60. I. Introduction
  61. ---------------
  62.  
  63. XPR Kermit implements the Kermit file transfer protocol in the form of
  64. an Amiga External Protocol (XPR) library.  This allows the addition of
  65. an up-to-date version of the Kermit protocol to any communications
  66. program which supports the XPR specification.  For further information
  67. on Kermit, read the book "Kermit:  A File Transfer Protocol" by Frank
  68. da Cruz, 1986, Digital Press.
  69.  
  70. Please note that this document assumes you already have some
  71. understanding of what the Kermit protocol is, and how to use it.  I
  72. have tried to include a few hints about common problems, but there is
  73. no substitute for obtaining and using a copy of the documentation for
  74. the Kermit on the other system to which you will be talking.  In
  75. addition, two commercial books are available.  "Kermit:  A File
  76. Transfer Protocol" by Frank da Cruz describes the protocol in some
  77. detail.  While aimed at those writing a Kermit program, it contains a
  78. good deal of useful information about Kermit itself.  "C Kermit" by
  79. Christine Gianone and Frank da Cruz, is a wealth of good introductory
  80. information about any version of Kermit.  In addition, the latter book
  81. is also the documentation for the standalone version of C Kermit which
  82. is available for the Amiga.
  83.  
  84. The Kermit protocol, and XPR Kermit, are copyright by Columbia
  85. University.  XPR Kermit is subject to the same restrictions as any
  86. other version of Kermit.  In particular, XPR Kermit may be included as
  87. part of a commercial package, provided the cost of said package is not
  88. increased as a result.
  89.  
  90. I cannot resist saying a few words in support of Kermit.  Unlike many
  91. other file transfer protocols such as the X/Y/ZMODEM family, the design
  92. of the Kermit protocol started with the assumption that communication
  93. lines are unreliable and quirky.  Kermit's slightly lower efficiency on
  94. good lines is more than compensated for by the fact that it can often
  95. successfully transfer files under conditions where other protocols
  96. fail.  It can transfer binary files over a seven-bit-wide communication
  97. line, or one which "eats" most control characters;  in fact, only two
  98. binary characters, the start-of-packet and end-of-packet markers, need
  99. be passed unchanged by the line.
  100.  
  101. II.  Installation
  102. -----------------
  103.  
  104. To install XPR Kermit, simply copy the file "xprkermit.library" to your
  105. LIBS: directory, and request your comm program to use XPRKERMIT as its
  106. external file transfer protocol.
  107.  
  108. XPR Kermit supports Version 2.0 of the XPR Protocol specification.  For
  109. more details on this, I recommend that you find a copy of the XPR
  110. Zmodem library, version 2.0.  Its documentation contains a good deal of
  111. the justification and philosophy of external protocol libraries, which
  112. I won't repeat here.  Among the programs supporting the XPR
  113. specification are the commercial programs A-Talk III and JRComm and the
  114. free programs VLT, Term, and NComm.
  115.  
  116.  
  117. III. Setting Options
  118. --------------------
  119.  
  120. XPR Kermit supports the parts of the Kermit protocol outlined in the
  121. table above.  There are currently nine user-settable parameters in XPR
  122. Kermit, which cover the parameters which are most often necessary to
  123. customize. If your communications problem is especially severe--for
  124. example, your method of connection to another system swallows
  125. characters which are special to Kermit, such as control-A--you may
  126. need to get a copy of the stand-alone Kermit program, C Kermit for the
  127. Amiga, distributed via many paths. The current version is 5A(189).
  128.  
  129. There are actually two sets of "setup" parameters in XPR Kermit.  The
  130. first set are commands which XPR Kermit can send to a remote Kermit
  131. server. These are not actually setups, but are in fact commands to XPR
  132. Kermit which cause it to communicate with a remote Kermit server.  The
  133. fourth command in this group is "Change Options," which causes no
  134. communication.  Instead, you are requested for changes in the current
  135. values of the parameters which Kermit will use for communication.
  136.  
  137. These items can be set in one of two ways.  One method is with a simple
  138. character string which is sent to XPR Kermit by the comm program;  this
  139. string will hereafter be referred to as the "init string."  This is
  140. generally done if an environment variable named XPRKERMIT exists and
  141. has a value, in which case XPR Kermit is sent the value when you first
  142. select XPR Kermit as your protocol.  Some comm programs also allow an
  143. initialization string to be sent in other ways, such as from a script;
  144. VLT, for example, has an INITXPR script command.  The format of this
  145. string is specified by the external protocol.
  146.  
  147. The second, more elegant method, is with some type of requester or set
  148. of requesters.  In this case, you will be presented by your comm
  149. program with a set of Intuition gadgets of some type which allow the
  150. choice of XPR Kermit commands and the setting of the options.
  151.  
  152. However, the string method has the advantage of giving one the ability
  153. to change external protocol settings non-interactively, such as from a
  154. script. In the case of XPR Kermit, such a script can actually command
  155. XPR Kermit to perform communication.  One obvious use of this is to
  156. transfer an entire directory tree from your Amiga to a remote machine: 
  157. you can make the remote Kermit a server and command it to perform the
  158. appropriate CD commands, then transfer files.
  159.  
  160. The currently supported XPR Kermit server commands are listed below.
  161. The format of the init string is in parentheses, generally simply a
  162. single letter.
  163.  
  164.     Kermit Finish (F):  Tells a Kermit server that you are done.  The
  165.     remote server will stop being a server.
  166.  
  167.     Kermit Bye (B):  Tells a Kermit server that you are done;  the server
  168.     will exit and log you off the remote machine.
  169.  
  170.     Kermit CD (C{dir}):  Change the default directory for files sent or
  171.     received by the Kermit server.  Examples of the init string would
  172.     be 'C/bin' or 'Cuser:[username.amiga]'.
  173.  
  174. For setting options via an init string, the first character of the init
  175. string must be the letter O (for Options).  Following that letter can
  176. be one or more of the option setting formats listed bellow;  these can
  177. be separated by whitespace and/or commas.
  178.  
  179. There are three settings which are either "yes" or "no."  Your comm
  180. program will give you some way of setting them interactively.  Simple
  181. button gadgets will be labeled "yes" and "no;"  otherwise, you may see
  182. a string gadget, into which you should type the word "yes" or "no" by
  183. hand.  This string is case-insensitive.  In the init-string, "yes" is
  184. represented by the single upper-case character Y.
  185.  
  186.     Convert FileName (C{Y|N}):  If "yes," then file names are
  187.     converted from Amiga file names to a "least common denominator"
  188.     form and back again.  On files which XPR Kermit sends, this
  189.     means that any leading directory path is stripped, and the file
  190.     name can consist of only upper case letters, numerals, and at
  191.     most one period.  Lower case letters are translated to upper
  192.     case, and non-alphanumeric characters, including extra periods,
  193.     are translated to X.  Received file names are converted to
  194.     lower case.  If "no," then none of these translations occur.
  195.     NOTE:  This means that files will often be sent with a complete
  196.     leading Amiga path name, and so you should make sure that you
  197.     send files with the comm program's current directory set to the
  198.     directory containing the file you're sending.  Default
  199.     "yes."
  200.  
  201.     Host Server (G{Y|N}):  If "yes," then the host (remote) Kermit is
  202.     assumed to be in server mode.  You will be prompted for file
  203.     names when you request an XPR Kermit receive, and this file
  204.     name will be sent to the server in the form of a Kermit GET
  205.     command.  Default "no."
  206.  
  207.     Keep Incomplete (K{Y|N}) If "yes," then incomplete files will be
  208.     kept.  An incomplete file can result from either an actual
  209.     error in the transfer, or a user-requested cancellation of
  210.     a transfer in process.  Default "no."
  211.  
  212.     Text File (T{Y|N}):  Flags whether the incoming file is text or binary.
  213.     If "yes," then carriage-return/line-feed pairs in the incoming
  214.     packets are converted to a single line-feed before writing the
  215.     packet to a file, and the opposite conversion is made when a file
  216.     is sent to a remote system.  Default "yes".
  217.  
  218.     If your communcations program supports its own text/binary flag
  219.     (that is, if the xpr_finfo() function exists and can tell XPR
  220.     Kermit whether a given file is text or binary), this option will
  221.     not appear.  Also, it is possible using attribute packets for the
  222.     sending Kermit to request switching from text to binary    and back
  223.     again on a per-file basis.  XPR Kermit fully supports this.  It
  224.     will switch if requested to by a sending Kermit.  When sending,
  225.     XPR Kermit uses the xpr_finfo() function on a per-file basis.  The
  226.     Amiga has no real way of determining whether a file is text or
  227.     binary, however, so it is usually up to the user to choose the
  228.     correct mode from a menu item or other setup in the comm
  229.     program.
  230.  
  231. Numerical or alphabetic settings are as follows.  Here, the init string
  232. key letter should be followed by a numerical or alphabetic value, as
  233. indicated.
  234.  
  235.     Packet Length (P{length}):  The Long Packets extension to Kermit is
  236.     fully supported. The longest possible packet is 9024;
  237.     the default value is 94, the longest standard Kermit packet.
  238.  
  239.     Block Check (B{type}):  This can have the value of 1, 2, or 3, and
  240.     chooses successively more stringent types of error checking on
  241.     the incoming data:  6-bit checksum, 12-bit checksum, and 16-bit
  242.     CRC, respectively.  Default is 1 (6-bit checksum).
  243.  
  244.     Timeout (O{seconds}):  The length of time the remote Kermit should wait
  245.     for a packet from XPR Kermit before assuming it isn't coming. The
  246.     default is 10 seconds.  See the extended discussion of timeouts
  247.     below.
  248.     (O is for Out, as in TimeOut;  T is already taken by the Text flag.)
  249.  
  250.      Retry Limit (R{number}):  The number of times XPR Kermit will attempt
  251.     to send or receive the next packet of data before quitting.  Notice
  252.     that if the remote end simply stops sending, a length of time equal
  253.     to the retry limit times the timeout will elapse before XPR Kermit
  254.     actually exits.  Default 5 retries.
  255.  
  256.      Window Size (W{number}):  The number of windows to use in the
  257.     sliding window extension to the protocol.  This is the number
  258.     of packets which XPR Kermit will send without waiting for an
  259.     acknowledgement from the other end.  Default 1, meaning sliding
  260.     windows are not used by default.
  261.     
  262.      File Name Collision action (N{X|A|D|R}):  What action to take if
  263.     a received file has the same name as an already existing file.
  264.     Each letter is a possible action, as follows:
  265.     X - Replace.  Unconditionally replace the old file with the
  266.     new one.
  267.     A - Append.  Append the incoming file to the end of the old
  268.     file.
  269.     D - Discard. Refuse to accept the incoming file.
  270.     R - Rename.  Rename the incoming file to a unique name by appending
  271.     a tilde followed by a sequence number to its name.
  272.  
  273.     The default is Replace.
  274.  
  275.      Send Packet Size and Send Timeout (SPn and SOn):  These values
  276.     override the ones requested by the Kermit at the other end for
  277.     the packet size and timeout, respectively, for XPR Kermit to
  278.     use when sending files to the other Kermit.  They should only
  279.     be used if there is good reason to believe that the values
  280.     requested by the other Kermit are not working well:  for
  281.     example, that you know more about the connection than the other
  282.     end does.  If these are zero, then the other end's requested
  283.     packet size and timeout are used.  The default is zero.
  284.  
  285. Setting a packet length larger than 94 (the default) enters long packet
  286. mode automatically.  If you use long packets, it is *strongly*
  287. recommended that you use block check 2 or 3 if the host Kermit supports
  288. them.  In addition, if binary files are to be transmitted, a higher
  289. block check than 1 should be used as well.
  290.  
  291. All of the above parameters, except the Send Overrides, correspond to
  292. the numbers set in a typical standalone Kermit program via the SET
  293. RECEIVE command. In the initial setup transaction for a Kermit file
  294. transfer, these values are sent to the Kermit at the other end as a
  295. request for it to use them when receiving packets from XPR Kermit.  The
  296. values for block check, timeout, window size, and packet length which
  297. XPR Kermit actually uses depend, in turn, on the ones requested by the
  298. Kermit at the other end. The block check, packet size, and window size
  299. used in the transaction will be the smaller of the values requested by
  300. the other Kermit and the values set by you in the XPR Kermit
  301. initialization.
  302.  
  303. Timeout settings are handled differently and are a bit confusing, I've
  304. found. The timeout set via XPR Kermit's requester is the length of time
  305. which XPR Kermit will request the other end to wait before assuming
  306. that XPR Kermit is not sending any response to the most recently sent
  307. packet. The length of time XPR Kermit should wait for a packet from the
  308. remote end is requested by the remote end, and is generally set by a
  309. SET RECEIVE TIMEOUT command typed by the user to the remote Kermit.
  310. With long packets at low baud rates (say, 2048 bytes at 1200 baud),
  311. both these times should be long enough to ensure an entire packet can
  312. be transferred in this time. The symptom if it is too short is that
  313. each packet will be sent exactly twice.  The same symptom can occur
  314. even if the connection between the remote Kermit and XPR Kermit is fast
  315. but has long transmission delays;  this is often the case when
  316. connected to a distant site via the Internet.
  317.  
  318. If you have problems such as these, try using the Send Overrides to change
  319. the values which XPR Kermit uses when sending packets.
  320.  
  321. Options can be mixed and matched.  For instance, to talk to a Kermit
  322. server with 750-byte packets, block check 2, keep incomplete files,
  323. binary files, five windows, and a 10-second timeout, the init string
  324. could be "OP750,B2,KY,TN,W5,O10".
  325.  
  326. III. Transferring Files
  327. -----------------------
  328.  
  329. Once XPR Kermit is set up, transferring files is as simple as with any
  330. of the protocols built in to your communication program.  Typically,
  331. you will log into a remote computer, start up its Kermit program, and
  332. issue the "send filename" or "receive" command to the remote Kermit.  A
  333. message will be printed, something like "Escape back to your local
  334. system and give a RECEIVE command" if you told the remote to send a
  335. file.  Issue the Receive File command to your terminal program;
  336. frequently, this is Right-Amiga-R.  Sit back and watch the file be
  337. transferred.
  338.  
  339. The files received by XPR Kermit are placed in the comm program's idea
  340. of its current directory;  that is, XPR Kermit asks the comm program to
  341. create a file of the same name as the file on the sending system, but
  342. leaves the directory in which the creation is to occur up to the comm
  343. program.  For sending files, path information is stripped from the file
  344. name before it is sent to the remote.
  345.  
  346. XPR Kermit supports multiple files on both send and receive.  Multiple
  347. received files are handled by the sending Kermit.  One almost always
  348. issues a wildcard send command, for example "send *.for" to send all
  349. Fortran files.  For sending multiple files, XPR Kermit queries the
  350. calling communication program for the names of the files to send, one
  351. at a time.  Check your program documentation for its method of
  352. supporting this.  Two common possibilities are simply the ability to
  353. type a wildcard into a string requester specifying the files to send,
  354. and being able to check multiple files in a list on a file requester.
  355.  
  356. If the "Host is Server" flag is set on the XPR Kermit options, it is
  357. assumed that you started the remote Kermit and issued the "SERVER"
  358. command to it.  When a remote Kermit is a server, it accepts incoming
  359. requests of a special format about which file to send.  On a
  360. command-line oriented version of Kermit, the command "GET filename"
  361. would be typed to the local Kermit, which would request the remote
  362. Kermit server to send that file.
  363.  
  364. XPR Kermit uses the protocol behind the Kermit GET command as well.  If
  365. the comm program sends XPR Kermit the name of a file or files to GET,
  366. for example from a script command, then that filename is used.  In the
  367. case of VLT, for example, the script command 'XPR RECEIVE "file"' will
  368. result in the file named "file" being used in XPR Kermit's GET command,
  369. provided the "Host is Server" flag is set. If no file name is sent to
  370. XPR Kermit by the comm program in this manner, the file or files to GET
  371. is requested interactively by XPR Kermit through the comm program. This
  372. will almost always happen when you issue an interactive "Receive File"
  373. command to the comm program. A string requester is almost always used
  374. here to prompt for the files to receive.  Note that this should be in
  375. the format of the *remote* system, not the Amiga. This is important for
  376. wildcards; SENDing a batch of Amiga files will generally use AmigaDOS
  377. wildcards (#?.for for all Fortran files), while a Unix, VAX/VMS, or
  378. MS/DOS system would use *.for for the same operation.
  379.  
  380. Most comm programs supply a nice status display, which XPR Kermit will
  381. update regularly to keep the user apprised of the transfer's progress.
  382. The name of the sent or received file will be shown.  If file name
  383. conversion is on, the converted name will appear after the word "as;"
  384. for example, 'Sending S:Startup-Sequence as STARTUPXSEQUENCE.'  The
  385. current packet count, packet length, packet type, timeout count, error
  386. count, number of file bytes transferred, elapsed time, and estimated
  387. total time are all updated after each attempt to transfer file data,
  388. whether the attempt is successful or not.  After the transfer
  389. completes, the total number of files, number of file bytes, elapsed
  390. time, and character-per-second (cps) transfer rate will be shown.
  391.  
  392. XPR Kermit supports three levels of transfer abort, out of the 33 which
  393. can be part of an XPR-supporting comm program.  The lowest level of an
  394. XPR abort is treated by XPR Kermit as a file abort, meaning that, if a
  395. batch transfer is in effect, the current file's transfer is interrupted
  396. but the protocol proceeds with the next file.  This is most useful in a
  397. wildcard transfer, where the wildcard matches a long file which you
  398. don't actually want transferred. The next higher level is treated as a
  399. batch abort, meaning that all files are cancelled.  Both of these
  400. aborts happen in a "graceful" way, which will not generally result in
  401. the remote Kermit exiting with an error status.  The highest level XPR
  402. Kermit abort, which is all many programs provide, is treated as an
  403. immediate stop-dead.  An error packet containing the string "User
  404. cancelled." is sent to the remote Kermit, the same message is echoed on
  405. the comm program status display, and XPR Kermit exits.  In addition, if
  406. the "Keep Incomplete Files" flag is OFF, the most recently received
  407. file will be deleted, if the cancelled transfer was a receive.
  408.  
  409. IV.  Credits
  410. ------------
  411.  
  412. The following people had a hand in this code.  In chronological order,
  413. they are:
  414.  
  415. -- Frank DaCruz of Columbia University, who deserves most of the credit
  416.    here.  The system-independent code in  the ckcfn?.c files is his,
  417.    and XPR Kermit is really just an interface to these files, which are
  418.    identical to the ones used in every other C language implementation
  419.    of Kermit.
  420. -- Marco Papa of Felsina Software, for the first beta XPR version
  421. -- Steve Walton, for second and subsequent XPR Kermit's.
  422.  
  423. Other acknowledgements go to Willy Langeveld for developing the XPR
  424. spec, and to Rick Huebner, several of whose ideas in XPR Zmodem were
  425. taken over into XPR Kermit by Steve Walton. Thank you all! 
  426.  
  427. V.  Gripes
  428. ----------
  429.  
  430. The current author and babysitter of this code is:
  431.  
  432.     Stephen Walton
  433.     Department of Physics and Astronomy
  434.     Cal State Northridge
  435.     18111 Nordhoff St.
  436.     Northridge, CA 91330 USA
  437.     (818) 885-2775
  438.  
  439. E-mail can go to:
  440.     swalton@solar.stanford.edu (Internet)
  441.  
  442. Thanks and congratulations gratefully accepted;  bug fixes and enhancements
  443. even more so!
  444.  
  445. VII.  Changes
  446. -------------
  447.  
  448. The following changes and improvements have been made to XPR Kermit since
  449. the release of version 1.111:
  450.  
  451. 1.  Attribute packets, file name collision handling, and sliding
  452. windows are all new in this version.
  453.  
  454. 2.  The system-independent C Kermit code is now used.  This means that,
  455. absent changes in the system-dependent routines required, XPR Kermit
  456. will automatically share in any improvements made to its big sister, C
  457. Kermit 5A(189).
  458.  
  459. 3.  The file transfer display code has been completely rewritten.  This
  460. was only possible because C Kermit already contains a system-dependent
  461. screen() function specification, which describes how to update the file
  462. transfer status display.  In fact, the screen() function in XPR Kermit
  463. is largely copied from the screenc() function in the Unix and Amiga
  464. versions of C Kermit.
  465.  
  466. The following improvements were made between version 1.5, the first
  467. release of XPR Kermit, and the second release, version 1.111.
  468.  
  469. 1. The library is now re-entrant.  This re-entrancy uses a bit of a "trick"
  470.    which depends on the mechanism used by Manx Aztec C to set up small
  471.    model programs.  I have successfully run two simultaneous file
  472.    transfers in XPR Kermit.
  473.  
  474. 2. The timeout code has been improved;  in fact, it appears that it may
  475.    not have worked at all in version 1.5.
  476.  
  477. 3. Block check type 2 did not work in version 1.5.
  478.  
  479. 3. A buffer overflow which could trash the high byte of an address on
  480.    an Amiga 3000 or other 68030-based machine was fixed.  This would
  481.    only be seen, normally, when sending a file with many repeated
  482.    characters.
  483.  
  484. 4. The "Keep incomplete file" feature is new.
  485.  
  486. 5. The file status display has been cleaned up somewhat;  in particular,
  487.    the previous file's final display should no longer show up when a
  488.    new transfer is started.  Timeouts are now counted separately from
  489.    other errors.
  490.  
  491. 6. Local buffers (that is, within XPR Kermit) have been added for both file
  492.    and communication line I/O.  This substantially reduces the number of
  493.    callbacks between XPR Kermit and the comm program, improving performance
  494.    under heavy multitasking. [Note added 3 Dec 1991:  an actual trial
  495.    on the local buffer for serial I/O indicated *worse* performance, so
  496.    the code is only compiled if the symbol MYREAD is #define'd in
  497.    kermitproto.c.  This is not the case in the distributed binary.]
  498.  
  499. 7. xpr_chkmisc() and xpr_chkabort() are now called properly.
  500.  
  501.  
  502. VI.  BUGS AND LIMITATIONS
  503. -------------------------
  504.  
  505. The file transfer cancellation button doesn't seem to work in Olaf
  506. Barthel's Term 3.2.  I have sent him e-mail about it.
  507.  
  508. The XPR protocol does not allow for the XPR to rename existing files.
  509. If it did, a "backup" option for file name collision detection would be
  510. possible. In this case, if an existing file has the same name as a
  511. received file, the existing file is renamed to a unique name and the
  512. received file is stored under its own name.  This is my personal
  513. preferred option, and is the default action with C Kermit.
  514.  
  515. The XPR protocol also does not allow one to find or set the
  516. modification date of a file.  If it did, then several additional
  517. features would become possible.  One would be  an "Update" option for
  518. filename collision, which would replace the existing file but only if
  519. the incoming file was newer.  XPR Kermit could also tell the receiving
  520. Kermit the modification date of a sent file, and set the modification
  521. date of a received file to agree with that on the sending system.
  522.  
  523. XPR Kermit is the largest of the XPR libraries, by a factor of three. 
  524. Because of this size, I have chosen not to implement one of the other
  525. major improvements of the most recent version of the Kermit protocol,
  526. namely support for international character sets.  If you need this
  527. feature, for example if you regularly transfer text files between
  528. machines in different countries, I recommend setting XPR Kermit to
  529. binary mode and setting the sending Kermit to use "ISO Latin-1" as its
  530. transfer character set.  Since the file character set of the Amiga is
  531. ISO Latin-1, this should result in a file transfer with all
  532. international characters intact, at the cost of a carriage return/line
  533. feed pair at the end of each text line, which can be trimmed after the
  534. file transfer.  If the remote system is a Unix system, or another
  535. Amiga, a binary-to-binary transfer of text files should work also.
  536.  
  537. XPR Kermit uses more memory than is strictly necessary, because both
  538. read-only and read-write data are copied for each comm program using
  539. XPR Kermit.  However, all file and communication buffers are allocated
  540. when needed, so this is not as important as it might first seem.  If
  541. international character sets were implemented, the large translation
  542. tables required would probably require an extensive rewrite of XPR
  543. Kermit to keep its memory usage reasonable.
  544.